Software Vault: The Gold Collection

home *** CD-ROM | disk | FTP | other *** search

/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr11 / sp144man.zip / APA.TXT next >

Wrap

Text File | 1993-04-19 | 13KB | 343 lines

APPENDIX A. ERROR/FLOW CONTROL CONCEPTS This appendix includes detailed information on how Sportster 14,400 modems use error control and, especially useful, some statistics and guidelines on using the modem for the best throughput. ERROR CONTROL AND THROUGHPUT OVERVIEW Error control protects the integrity of data transferred over phone channels and is available for calls at 1200 bps and above. It can be disabled, although high speed calls (above 2400 bps) should always be under error control. The operations defined in an error-control protocol include the following. ∙ Establishment of compatibility ∙ Data formatting into blocks or (MNP) frames ∙ Error detection through Cyclic Redundancy Checking (CRC) ∙ Positive acknowledgment of error- free blocks and negative acknowledgment of corrupted data blocks ∙ Retransmission of corrupted data blocks The Sportster 14,400 is set at the factory to &M4, causing it to try for an error-control connection and, if that isn't possible, to proceed with the call in Normal mode. The modem first tries for a V.42 connection, then an MNP connection. The following infor mation is based on the Sportster 14,400's setting of &M4. CCITT V.42 HANDSHAKING The exchange of signals between two devices in order to establish a communications link is called handshaking. CCITT V.42 includes a two- stage handshaking process. ∙ A Detection phase that is based on an exchange of predefined characters. ∙ LAPM (Link Access Procedures for Modems) Negotiation. In this phase, the modems identify their capabilities concerning maximum data block size and the number of outstanding data blocks allowed before an acknowledgment is required. MNP HANDSHAKING This protocol is supported by the CCITT V.42 Recommendation. It was originally developed by Microcom, Inc., and is now in the public domain. MNP handshaking begins with an MNP Link Request sent by the calling modem. If the remote modem doesn't recognize the request, error control isn't possible. DATA COMPRESSION If the modems successfully establish a V.42 connection, they also negotiate for V.42 bis data compression. If they successfully establish an MNP connection, they negotiate for MNP5 data compression. Modems using V.42 bis compression negotiate the following options. ∙ Dictionary size, that is, the amount of memory available for compression table entries. (Entries are codes devised for redundant data. The data is packed into shorter data units, called code words, and unpacked by the receiving modem.) Possible sizes are as follows. USRobotics modems use 11-bit, or 2048-entry dictionaries, but drop down if the remote modem uses a 512- or 1024-entry dictionary. BitsEntries 9 512 10 1024 11 2048 ∙ Maximum string length of each entry. As the dictionary fills, the modem deletes the oldest unused strings. V.42 bis compression is more efficient than MNP5 compression in part because it dynamically deletes unusable strings. In addition, it works better with files that are already compressed. These include already compressed files, such as the .ZIP files downloaded from many Bulletin Boards, and 8-bit binary files, which appear to the modem to be compressed. MNP5 compression should not be used with such files because it adds data to them, which lessens throughput. (The additional data is stripped when the file is decompressed by the remote modem.) When transferring such files, it's best to set the modem to &K3: this allows V.42 bis compression to work dynamically with the compressed data, but disables MNP5. FLOW CONTROL Flow control of data from the computer or terminal is required under error control for two reasons. 1.The transmitting modem buffers a copy of each frame it transmits to the remote end until it is acknowledged by the receiving modem. 2.If errors are encountered, the transmitting modem must resend the corrupted data. This retransmission activity, combined with the steady stream of data from the computer or terminal, can overflow the buffer. THROUGHPUT GUIDELINES The following guidelines should help to make the most of the modem's advanced performance features. In many instances, experimentation and experience will indicate what works best for your applications. 1.Optimal throughput is attained under the following conditions. ∙ The communications software allows fixing the serial port rate higher than the connection rate, for example, setting the software to 38.4K bps and setting the modem to &B1. If the software automatically switches bit rates to follow the connection rate, the modem's serial port rate also must be set to follow the connection rate for each call, &B0, and throughput will be limited. ∙ The call is under data compression. ∙ The data is comprised of text files rather than binary files such as .EXE or .COM files. See the table at the end of this appendix. 2.Disable MNP5 compression for files that are already compressed, or 8-bit binary files, which appear to the mo dem to be already compressed. Set the modem to &K3, which disables MNP5 and leaves V.42 bis compression enabled. 3.Many non-text files require a file- transfer protocol. The file transfer may be slowed down by a file-transfer protocol, but the results vary. For example, certain public domain file- transfer protocols have the following effects. KermitWith the basic Kermit, throughput is severely reduced due to short block lengths (under 128 bytes) and acknowledgment turnaround time. Later enhancements to Kermit permit larger data- block lengths. XmodemThroughput may be reduced if your version uses short block lengths, for example, 128 bytes. Some versions use blocks of 1 Kbyte, which is much better, although overhead (error-control protocol information) still affects overall throughput. YmodemThis protocol is similar to Xmodem with 1-Kbyte block lengths, and allows multiple files to be sent in one transfer. These file-transfer protocols further reduce throughput when an error- control connection is established. The accuracy of the data is checked twice, by the file-transfer protocol and the modem. To avoid redundancy, use these protocols only for non-ARQ connections. For better throughput, we recommend Ymodem-G, with the modem left at its error-control default, &M4. Ymodem-G assumes the modems are handling error control: overhead is minimal, with throughput almost equal to that obtained with no file-transfer protocol. However, keep in mind that Ymodem-G is only useful if the modems are using error control. In addition, follow this recommendation only if your machine and software support hardware flow control. On the other hand, the most current version of Zmodem can yield even greater efficiency. Leave the modem at its error-control default (&M4) and data compression default, &K1. Zmodem performs the same kind of com pression as V.42 bis; it turns off its compression if files are already compressed. ONLINE FALLBACK/FALL FORWARD Under error control, if a disturbance on the phone line causes an error to a data block, the receiving modem replies with a negative acknowledgment. In response, the transmitting modem retrieves a copy of the original data block from its Transmit buffer, and every block it sent after that block, and retransmits them. This keeps the data error-free and in sequence. However, there is a retransmit limit: the modems hang up if line disturbances are so severe that one of the modems has retransmitted the same block of data twelve times without a positive acknowledgment. High-speed calls are more vulnerable than transmission at 2400 bps and below. In order to keep V.32 bis modems online above 2400 bps, instead of reaching the retransmit limit and hanging up, one of the modems requests that they fall back, that is, that they reduce their rate from 14.4K to 12K bps, and then to 9600 bps or lower, if necessary. When online conditions improve, the modems fall forward to the next higher speed, up to the link rate of the call. ACHIEVABLE THROUGHPUT STATISTICS The table below indicates the maximum throughput, in characters per second (cps), that can be expected under the following optimal conditions. ∙ Serial port rate set at 57.6K bps; modem set to &B1 (Note that both your software and your computer must support 57.6K bps in order for you to use that rate) ∙ Connection (link) rate of 14.4K bps (assuming no protective fallback to a lower speed is necessary) ∙ V.42 bis compression negotiated for the call, and the default size 11- bit, 2048-entry dictionary ∙ Straight data (that is, not already compressed, no file-transfer protocol) ∙ Transmission from a fast (for example, 286) computer Throughput (cps) when set to 14.4K bps File Type MNP5 V.42 bis Assembler or Compiler listing 2880 3840 Text file 2325-2625 3400-5760 Binary file: .EXE 2175-2400 2030-2600 Binary file: .COM 2100-2250 2050-2300 .ZIP files (common on BBS's)* 1500-1650 1700 Random binary 8-bit* 1460-1575 1700 * These files are already compressed or appear to the modem to be com pressed. Additional MNP5 compres sion causes throughput lower than what can be expected using MNP without compression. We recommend setting the modem to &K3 when transferring these files, to allow V.42 bis but disable MNP5. The following table indicates the maximum throughput, in characters per second (cps), that can normally be expected in the same conditions as the previous table , but with a serial port rate of 38.4K bps. Throughput (cps) when set to 14.4K bps File Type MNP5 V.42 bis Assembler or Compiler listing 2880 3840 Text file 2325-2625 3400-3480 Binary file: .EXE 2175-2400 2030-2600 Binary file: .COM 2100-2250 2050-2300 .ZIP files (common on BBS's)* 1500-1650 1700 Random binary 8-bit* 1460-1575 1700 *We recommend setting the modem to &K3 when transferring these types of files. See the note attached to the previous table.